\documentclass[a4paper,11pt]{article}
\usepackage{geometry}
\usepackage{color}
\usepackage{listings}
\usepackage{hyperref}
\usepackage{amsmath}
\usepackage{url}
\usepackage{parsetree}
\usepackage{graphics}
\usepackage{clrscode3e}
\usepackage{avm}
\usepackage{tree-dvips}
\usepackage{fancyhdr}

\setlength{\hoffset}{0in}
\setlength{\voffset}{0in}
\setlength{\oddsidemargin}{0in}
\setlength{\topmargin}{0in}
\setlength{\headheight}{0pt}
\setlength{\headsep}{25pt}
\setlength{\textheight}{10in}
\setlength{\textwidth}{6.27in}
\setlength{\marginparsep}{0in}
\setlength{\marginparwidth}{0in}
\setlength{\footskip}{0pt}
\setlength{\parindent}{0pt}
\setcounter{secnumdepth}{0}

% Indentation commands for CLRS
\newcommand{\ii}{\ \ \ \ \ }
\newcommand{\iii}{\ii\ii}
\newcommand{\iiii}{\iii\ii}
\newcommand{\iiiii}{\iiii\ii}
\newcommand{\iiiiii}{\iiiii\ii}
\newcommand{\iiiiiii}{\iiiiii\ii}
\newcommand{\iiiiiiii}{\iiiiiii\ii}

% Monospace
\newcommand{\m}[1]{\texttt{#1}}

% For all Such That, to be used in equations
\newcommand{\fas}[1]{\text{ for all }#1\text{ such that }}

% Quicker itemizing
\renewcommand{\i}{\item[]}
\renewcommand{\b}{\begin{itemize}}
\newcommand{\e}{\end{itemize}}

% Left/Right
\renewcommand{\l}{\left}
\renewcommand{\r}{\right}

% Displaystyle
\newcommand{\ds}{\displaystyle}

\pagestyle{fancy}
% Header
\renewcommand{\headrulewidth}{0.4pt}
\fancyhead{}
\fancyhead[L]{\Large{Team Rocket} \hfill \scriptsize{Design Twist \ \ $\cdot$ \ \ \today}\normalsize{}}

% Footer
\fancyfoot{}
\fancyfoot[C]{\thepage}
\begin{document}

Just a note: We implemented a system for a pokemon center, which is remarkably similar to a vet's office. So for our design twist we were told to work the other direction and use our software for a regular doctor's office. \\

Because our project was heavily object oriented it was incredibly simple to modify our project. The only thing that needed to occur was to modify the trainers to be the ones getting treatments rather than their pokemon. This is because we made everything very generic and detached so that it could be reused when needed, this is one principle that has helped alot throughout this project not having every class depend on every other one to be working. \\

Along with the association change a few GUI screens would need to be updated, so that the focus is on the trainer rather than the pokemon. Since we are not implementing it I will just be assuming that most of the code would need to be glanced over and the book-keeping in a few places could need to be changed, but no logical changes would need to take place. The database would also need to be updated to account for the different statuses and treatments that are relavent to trainers and not pokemon. \\

Throughout the changes we did not implement any additional patterns, but I will go over the ones we currently have in our project. \\

Mediator: The mediator pattern provides a universal object that all of the clients and servers can communicate with. This helps when multiple clients are trying to update something in the database, lets say, a nurse and doctor are both trying to schedule an appointment at the same time. The mediator can handle clashes like this and force the outdated client to update itself to the most current version. \\

Router: The router pattern is used to pass different commands to the appropriate place. Perhaps one command should open up a confirmation window, while another type of command should change a value in the database, or perhaps an object passed in isn't a command at all and needs to be sent to the correct output. The router handles this traffic appropriately. \\

Handler: The handler pattern is what actually handles a certain command, or object. If there a preconditions to a certain command, or if there were some post condition that would be the handlers job. It would also be able to do some exception handling depending on the specific command. The router would have a list of handlers and if appropriate might pass certain objects to the correct handler. \\

CommandQueue: The CommandQueue or Worker Pool patter is used so that each action doesn't start a new thread. Rather a pool of threads pulls from a Queue of actions. This is similar to the java Executer class, however we chose to implement our own version for more control and more experience. \\

These are just a few of the patterns we implemented, there are quite a few more I won't mention here. All of them made it very easy to decouple certain functions of our application that allows it to be very versatile, hence it was easy to accomodate the design twist. \\

The two main diagrams are System.png, and UserInformation.png. System.png did not change, however some small sections of code would need to be updated. Mainly things like changing createPokemon() to createTrainer() and updating fields, things like that. UserInformation.png had a very minor change, and would likely require less of a cooding update than the System.
\end{document}